home *** CD-ROM | disk | FTP | other *** search
/ Archive Magazine CD 1995 / Archive Magazine CD 1995.iso / discs / prog_disc / volume_8 / issue_06 / risc_os / kernel / ModeExtend < prev    next >
Encoding:
Text File  |  1988-09-28  |  5.3 KB  |  148 lines
  1. ; > &.Doc180.Kernel.ModeExtend
  2.  
  3. Title:          Mode extensions/1
  4. Version:        0.02
  5. Started:        21-Mar-88
  6. Last updated:   28-Sep-88
  7.  
  8. In RISC OS 2.00 it is possible to load modules which provide additional
  9. screen modes and additional monitor types. To provide this facility a number
  10. of new services are offered:-
  11.  
  12. Service_ModeExtension (&50)
  13. ---------------------------
  14.  
  15. in:     R1 = Service_ModeExtension
  16.         R2 = mode number that information is requested for
  17.         R3 = monitor type (or -1 for don't care)
  18.  
  19. out:    (If not claimed)
  20.         All registers preserved
  21.  
  22.         (If claimed)
  23.         R1 = 0
  24.         R2 preserved
  25.         R3 -> VIDC list
  26.         R4 -> workspace list
  27.  
  28. Format of VIDC list (all word values)
  29. -------------------------------------
  30.  
  31. Offset          Value
  32.  
  33. 0               0 (indicates format of list, to allow for new VIDCs at a
  34.                 later date)
  35. 4               VIDC base mode
  36. 8               VIDC parameter
  37. 12              VIDC parameter
  38. .               .
  39. .               .
  40. n               -1
  41.  
  42. The VIDC base mode is the number of an existing operating system screen mode
  43. which is used to determine the values of VIDC registers not explicitly
  44. mentioned in the list. The VIDC parameters are in the form that would be
  45. written to the hardware ie the top 6 bits specify which register is
  46. programmed and the remainder specify the value to be programmed in that
  47. register. However, bits 6 and 7 of the control register should be set to 0 as
  48. these will be modified by the MOS to take the configured sync and the *TV
  49. interlace setting into account. Similarly the vertical parameters for border
  50. start, display start, display end and border end are modified by the MOS to
  51. take the *TV vertical offset into account.
  52.  
  53. VIDC parameters below &80000000 are ignored, since these correspond to
  54. palette registers (determined by the workspace base mode) and sound registers
  55. (not part of the display system).
  56.  
  57. Format of workspace list (all word values)
  58. ------------------------------------------
  59.  
  60. Offset          Value
  61.  
  62. 0               0 (indicates format of list)
  63. 4               Workspace base mode
  64. 8               Mode variable index
  65. 12              Mode variable value
  66. 16              Mode variable index
  67. 20              Mode variable value
  68. .               .
  69. .               .
  70. n               -1
  71.  
  72. The workspace base mode is the number of an existing operating system screen
  73. mode which is used to determine the values of mode variables not explicitly
  74. mentioned in the list. The mode variable indices are the same as for
  75. SWI OS_ReadModeVariable.
  76.  
  77. Note: for the palette to be set properly, a workspace base mode should be
  78. chosen which has the appropriate palette.
  79.  
  80. When the service is received, the module should check that R2 contains a mode
  81. that it knows about and that R3 holds a monitor type that is suitable for
  82. that mode. If not, the service should be passed on. If R3 holds -1 then the
  83. MOS is making a general enquiry about that mode (eg to determine the attributes
  84. of a sprite defined in that mode) so the module should only check R2.
  85.  
  86. Note that it is possible for a mode to have two or more different sets of
  87. VIDC parameters for different monitor types, but the workspace parameters
  88. MUST be the same, as the mode number is used as an identifier in sprites and
  89. in calls such as OS_ReadModeVariable.
  90.  
  91.  
  92. Service_ModeTranslation (&51)
  93. -----------------------------
  94.  
  95. in:     R1 = Service_ModeTranslation
  96.         R2 = mode number that requires translation
  97.         R3 = monitor type
  98.  
  99. out:    (If not claimed)
  100.         All registers preserved
  101.  
  102.         (If claimed)
  103.         R1 = 0
  104.         R2 = substitute mode
  105.         R3 preserved
  106.  
  107. This service is offered during a call to OS_CheckModeValid or a screen mode
  108. change, if the selected mode is not available with the current monitor type
  109. (this having been ascertained by offering Service_ModeExtension) and the
  110. monitor type is not one known to the MOS (ie not in the range 0..3). If the
  111. monitor type passed in R3 is known to the module, then the module should
  112. discover what the attributes of the mode in R2 are (by calling
  113. ReadModeVariable) and then choose a mode which is suitable for this monitor
  114. type and is closest in attributes to the selected mode. This mode number
  115. should be returned in R2.
  116.  
  117. Service_PreModeChange (&4D)
  118. ---------------------------
  119.  
  120. in:     R1 = Service_PreModeChange
  121.         R2 = selected mode (before possible translation)
  122.  
  123. out:    (Case 1)
  124.         All registers preserved
  125.         This is the normal action for a module which does not want to
  126.         interfere.
  127.  
  128.         (Case 2)
  129.         R1 = 0 (service claimed)
  130.         R0 = 0
  131.         This implies that the module does not want the mode change to take
  132.         place, and has taken an alternative action.
  133.  
  134.         (Case 3)
  135.         R1 = 0 (service claimed)
  136.         R0 -> error block
  137.         This implies that the module does not want the mode change to take
  138.         place, and wishes to return the error pointed to by R0
  139.  
  140.         (Case 4 - possibly to be removed)
  141.         R1 preserved
  142.         R2 = new mode
  143.         This implies that the module wants to substitute a mode for the
  144.         specified mode. This is not a very good way of doing it, as other
  145.         modules further down the chain will be offered the service with this
  146.         new mode. The Service_ModeTranslation mechanism described above should
  147.         be used by modules providing new monitor types.
  148.